<!doctype html>
<html lang="en">
    <head>
        <meta charset="utf-8">
        <title>testssl.sh</title>
        <style type='text/css' media='all'>
            body {
                margin: 0;
                padding: 0 5ex;
                font-size: 14px;
                font-family: monospace;
                text-align: justify;
            }
            h2, h3, h4, h5, h6 {
                color: #030201;
            }
            h2 {
                font-size: 16px;
            }
            h3 {
                font-size: 15px;
                margin-left: 4ex;
            }
            p, pre, ul, ol, dl {
                margin-left: 8ex;
            }
            code {
                font-weight: bold;
                color:#131211;
            }
            li p {
                margin-left: 0;
            }
            pre > code {
                display: block;
                padding: 0;
                white-space: pre-line;
            }
            ul > li > ul, ul > li > ol {
                margin-left: 0;
            }
        </style>
    </head>
    <body>
        <h2 id="name">NAME</h2>
        <p>testssl.sh – check encryption of SSL/TLS servers</p>
        <h2 id="synopsis">SYNOPSIS</h2>
        <p><code>testssl.sh [OPTIONS] &lt;URI&gt;</code>,
        <code>testssl.sh [OPTIONS] --file &lt;FILE&gt;</code></p>
        <p>or</p>
        <p><code>testssl.sh [BANNER OPTIONS]</code></p>
        <h2 id="description">DESCRIPTION</h2>
        <p>testssl.sh is a free command line tool which checks a
        server’s service on any port for the support of TLS/SSL ciphers,
        protocols as well as cryptographic flaws and much more.</p>
        <p>The output rates findings by color (screen) or severity (file
        output) so that you are able to tell whether something is good
        or bad. The (screen) output has several sections in which
        classes of checks are being performed. To ease readability on
        the screen it aligns and indents the output properly.</p>
        <p>Only you see the result. You also can use it internally on
        your LAN. Except DNS lookups or unless you instruct testssl.sh
        to check for revocation of certificates it doesn’t use any other
        hosts or even third parties for any test.</p>
        <h2 id="requirements">REQUIREMENTS</h2>
        <p>Testssl.sh is out of the box portable: it runs under any
        Unix-like stack: Linux, *BSD, MacOS X, WSL=Windows Subsystem for
        Linux, Cygwin and MSYS2. <code>bash</code> is a prerequisite,
        also version 3 is still supported. Standard utilities like awk,
        sed, tr and head are also needed. This can be of a BSD, System 5
        or GNU flavor whereas grep from System V is not yet
        supported.</p>
        <p>Any OpenSSL or LibreSSL version is needed as a helper. Unlike
        previous versions of testssl.sh almost every check is done via
        (TCP) sockets. In addition statically linked OpenSSL binaries
        for major operating systems are supplied in
        <code>./bin/</code>.</p>
        <h2 id="general">GENERAL</h2>
        <p><code>testssl.sh URI</code> as the default invocation does
        the so-called default run which does a number of checks and puts
        out the results colorized (ANSI and termcap) on the screen. It
        does every check listed below except <code>-E</code> which are
        (order of appearance):</p>
        <ol start="0" type="1">
        <li><p>displays a banner (see below), does a DNS lookup also for
        further IP addresses and does for the returned IP address a
        reverse lookup. Last but not least a service check is being
        done.</p></li>
        <li><p>SSL/TLS protocol check</p></li>
        <li><p>standard cipher categories</p></li>
        <li><p>server’s cipher preferences (server order?)</p></li>
        <li><p>forward secrecy: ciphers and elliptical curves</p></li>
        <li><p>server defaults (certificate info, TLS extensions,
        session information)</p></li>
        <li><p>HTTP header (if HTTP detected or being forced via
        <code>--assume-http</code>)</p></li>
        <li><p>vulnerabilities</p></li>
        <li><p>testing each of 370 preconfigured ciphers</p></li>
        <li><p>client simulation</p></li>
        <li><p>rating</p></li>
        </ol>
        <p>If a target FQDN has multiple IPv4 and/or multiple IPv6
        addresses, it scans all IPs with the specified options or using
        the default run - unless specified otherwise, see
        <code>--ip</code>, <code>-4</code> and <code>-6</code>. IPv6
        connectivity is automagically checked. If there’s noch such
        thing you will see a banner <em>Testing all
        <strong>IPv4</strong> addresses</em> and all IPv6 addresses will
        appear in round brackets.</p>
        <h2 id="options-and-parameters">OPTIONS AND PARAMETERS</h2>
        <p>Options are either short or long options. Any long or short
        option requiring a value can be called with or without an equal
        sign. E.g.
        <code>testssl.sh -t=smtp --wide --openssl=/usr/bin/openssl &lt;URI&gt;</code>
        (short options with equal sign) is equivalent to
        <code>testssl.sh --starttls smtp --wide --openssl /usr/bin/openssl &lt;URI&gt;</code>
        (long option without equal sign). Some command line options can
        also be preset via ENV variables.
        <code>WIDE=true OPENSSL=/usr/bin/openssl testssl.sh --starttls=smtp &lt;URI&gt;</code>
        would be the equivalent to the aforementioned examples.
        Preference has the command line over any environment
        variables.</p>
        <p><code>&lt;URI&gt;</code> or <code>--file &lt;FILE&gt;</code>
        always needs to be the last parameter.</p>
        <h3 id="banner-options-standalone">BANNER OPTIONS
        (standalone)</h3>
        <p><code>--help</code> (or no arg) displays command line
        help</p>
        <p><code>-b, --banner</code> displays testssl.sh banner,
        including license, usage conditions, version of testssl.sh,
        detected openssl version, its path to it, # of ciphers of
        openssl, its build date and the architecture.</p>
        <p><code>-v, --version</code> same as before</p>
        <p><code>-V [pattern], --local [pattern]</code> pretty print all
        local ciphers supported by openssl version. If a pattern is
        supplied it performs a match (ignore case) on any of the strings
        supplied in the wide output, see below. The pattern will be
        searched in the any of the columns: hexcode, cipher suite name
        (OpenSSL or IANA), key exchange, encryption, bits. It does a
        word pattern match for non-numbers, for number just a normal
        match applies. Numbers here are defined as [0-9,A-F]. This means
        (attention: catch) that the pattern CBC is matched as non-word,
        but AES as word. This option also accepts
        <code>--openssl=&lt;path_to_openssl&gt;</code>.</p>
        <h3 id="input-parameters">INPUT PARAMETERS</h3>
        <p><code>URI</code> can be a hostname, an IPv4 or IPv6 address
        (restriction see below) or an URL. IPv6 addresses need to be in
        square brackets. For any given parameter port 443 is assumed
        unless specified by appending a colon and a port number. The
        only preceding protocol specifier allowed is <code>https</code>.
        You need to be aware that checks for an IP address might not hit
        the vhost you want. DNS resolution (A/AAAA record) is being
        performed unless you have an <code>/etc/hosts</code> entry for
        the hostname.</p>
        <p><code>--file &lt;fname&gt;</code> or the equivalent
        <code>-iL &lt;fname&gt;</code> are mass testing options. Per
        default it implicitly turns on <code>--warnings batch</code>,
        unless warnings has been set to off before. In its first
        incarnation the mass testing option reads command lines from
        <code>fname</code>. <code>fname</code> consists of command lines
        of testssl, one line per instance. Comments after <code>#</code>
        are ignored, <code>EOF</code> signals the end of fname any
        subsequent lines will be ignored too. You can also supply
        additional options which will be inherited to each child,
        e.g. When invoking
        <code>testssl.sh --wide --log --file &lt;fname&gt;</code> . Each
        single line in <code>fname</code> is parsed upon execution. If
        there’s a conflicting option and serial mass testing option is
        being performed the check will be aborted at the time it occurs
        and depending on the output option potentially leaving you with
        an output file without footer. In parallel mode the mileage
        varies, likely a line won’t be scanned.</p>
        <p>Alternatively <code>fname</code> can be in
        <code>nmap</code>’s grep(p)able output format
        (<code>-oG</code>). Only open ports will be considered. Multiple
        ports per line are allowed. The ports can be different and will
        be tested by testssl.sh according to common practice in the
        internet, i.e. if nmap shows in its output an open port 25,
        automatically <code>-t smtp</code> will be added before the URI
        whereas port 465 will be treated as a plain TLS/SSL port, not
        requiring an STARTTLS SMTP handshake upfront. This is done by an
        internal table which correlates nmap’s open port detected to the
        STARTTLS/plain text decision from testssl.sh.</p>
        <p>Nmap’s output always returns IP addresses and only if there’s
        a PTR DNS record available a hostname. As it is not checked by
        nmap whether the hostname matches the IP (A or AAAA record),
        testssl.sh does this automatically for you. If the A record of
        the hostname matches the IP address, the hostname is used and
        not the IP address. Please keep in mind that checks against an
        IP address might not hit the vhost you maybe were aiming at and
        thus it may lead to different results.</p>
        <p>A typical internal conversion to testssl.sh file format from
        nmap’s grep(p)able format could look like:</p>
        <pre><code>  10.10.12.16:443
  10.10.12.16:1443
  -t smtp host.example.com:25
  host.example.com:443
  host.example.com:631
  -t ftp 10.10.12.11:21
  10.10.12.11:8443</code></pre>
        <p>Please note that <code>fname</code> has to be in Unix format.
        DOS carriage returns won’t be accepted. Instead of the command
        line switch the environment variable FNAME will be honored
        too.</p>
        <p><code>--mode &lt;serial|parallel&gt;</code>. Mass testing to
        be done serial (default) or parallel (<code>--parallel</code> is
        shortcut for the latter, <code>--serial</code> is the opposite
        option). Per default mass testing is being run in serial mode,
        i.e. one line after the other is processed and invoked. The
        variable <code>MASS_TESTING_MODE</code> can be defined to be
        either equal <code>serial</code> or <code>parallel</code>.</p>
        <p><code>--warnings &lt;batch|off&gt;</code>. The warnings
        parameter determines how testssl.sh will deal with situations
        where user input normally will be necessary. There are two
        options. <code>batch</code> doesn’t wait for a confirming
        keypress when a client- or server-side problem is encountered.
        As of 3.0 it just then terminates the particular scan. This is
        automatically chosen for mass testing (<code>--file</code>).
        <code>off</code> just skips the warning, the confirmation but
        continues the scan, independent whether it makes sense or not.
        Please note that there are conflicts where testssl.sh will still
        ask for confirmation which are the ones which otherwise would
        have a drastic impact on the results. Almost any other decision
        will be made in the future as a best guess by testssl.sh. The
        same can be achieved by setting the environment variable
        <code>WARNINGS</code>.</p>
        <p><code>--socket-timeout &lt;seconds&gt;</code> This is useful
        for socket TCP connections to a node. If the node does not
        complete a TCP handshake (e.g. because it is down or behind a
        firewall or there’s an IDS or a tarpit) testssl.sh may usually
        hang for around 2 minutes or even much more. This parameter
        instructs testssl.sh to wait at most <code>seconds</code> for
        the handshake to complete before giving up. This option only
        works if your OS has a timeout binary installed. SOCKET_TIMEOUT
        is the corresponding environment variable. This doesn’t work on
        Macs out of the box.</p>
        <p><code>--openssl-timeout &lt;seconds&gt;</code> This is
        especially useful for all connects using openssl and practically
        useful for mass testing. It avoids the openssl connect to hang
        for ~2 minutes. The expected parameter <code>seconds</code>
        instructs testssl.sh to wait before the openssl connect will be
        terminated. The option is only available if your OS has a
        timeout binary installed. As there are different implementations
        of <code>timeout</code>: It automatically calls the binary with
        the right parameters. OPENSSL_TIMEOUT is the equivalent
        environment variable. This doesn’t work on Macs out of the
        box.</p>
        <p><code>--basicauth &lt;user:pass&gt;</code> This can be set to
        provide HTTP basic auth credentials which are used during checks
        for security headers. BASICAUTH is the ENV variable you can use
        instead.</p>
        <p><code>--reqheader &lt;header&gt;</code> This can be used to
        add additional HTTP request headers in the correct format
        <code>Headername: headercontent</code>. This parameter can be
        called multiple times if required. For example:
        <code>--reqheader 'Proxy-Authorization: Basic dGVzdHNzbDpydWxlcw==' --reqheader 'ClientID: 0xDEADBEAF'</code>.
        REQHEADER is the corresponding environment variable.</p>
        <p><code>--mtls &lt;path_to_client_cert&gt;</code> This can be
        set to provide a file containing a client certificatete and a
        private key (not encrypted) in PEM format, which is used when a
        mutual TLS authentication is required by the remote server. MTLS
        is the equivalent environment variable.</p>
        <h3 id="special-invocations">SPECIAL INVOCATIONS</h3>
        <p><code>-t &lt;protocol&gt;, --starttls &lt;protocol&gt;</code>
        does a default run against a STARTTLS enabled
        <code>protocol</code>. <code>protocol</code> must be one of
        <code>ftp</code>, <code>smtp</code>, <code>pop3</code>,
        <code>imap</code>, <code>xmpp</code>, <code>sieve</code>,
        <code>xmpp-server</code>, <code>telnet</code>,
        <code>ldap</code>, <code>irc</code>, <code>lmtp</code>,
        <code>nntp</code>, <code>postgres</code>, <code>mysql</code>.
        For the latter four you need e.g. the supplied OpenSSL or
        OpenSSL version 1.1.1. Please note: MongoDB doesn’t offer a
        STARTTLS connection, IRC currently only works with
        <code>--ssl-native</code>. <code>irc</code> is WIP.</p>
        <p><code>--xmpphost &lt;jabber_domain&gt;</code> is an
        additional option for STARTTLS enabled XMPP: It expects the
        jabber domain as a parameter. This is only needed if the domain
        is different from the URI supplied.</p>
        <p><code>--mx &lt;domain|host&gt;</code> tests all MX records
        (STARTTLS on port 25) from high to low priority, one after the
        other.</p>
        <p><code>--ip &lt;ip&gt;</code> tests either the supplied IPv4
        or IPv6 address instead of resolving host(s) in
        <code>&lt;URI&gt;</code>. IPv6 addresses need to be supplied in
        square brackets. <code>--ip=one</code> means: just test the
        first A record DNS returns (useful for multiple IPs). If
        <code>-6</code> and <code>--ip=one</code> was supplied an AAAA
        record will be picked if available. The <code>--ip</code> option
        might be also useful if you want to resolve the supplied
        hostname to a different IP, similar as if you would edit
        <code>/etc/hosts</code> or
        <code>/c/Windows/System32/drivers/etc/hosts</code>.
        <code>--ip=proxy</code> tries a DNS resolution via proxy.
        <code>--ip=proxy</code> plus <code>--nodns=min</code> is useful
        for situations with no local DNS as there’ll be no DNS timeouts
        when trying to resolve CAA, TXT and MX records.</p>
        <p><code>--proxy &lt;host&gt;:&lt;port&gt;</code> does ANY check
        via the specified proxy. <code>--proxy=auto</code> inherits the
        proxy setting from the environment. Any hostname supplied will
        be resolved to the first A record, if it does not exist the AAAA
        record is used. IPv4 and IPv6 addresses can be passed too, the
        latter <em>also</em> with square bracket notation. Please note
        that you need a newer OpenSSL or LibreSSL version for IPv6 proxy
        functionality. In addition if you want lookups via proxy you can
        specify <code>DNS_VIA_PROXY=true</code>. OCSP revocation
        checking (<code>-S --phone-out</code>) is not supported by
        OpenSSL via proxy. As supplying a proxy is an indicator for port
        80 and 443 outgoing being blocked in your network an OCSP
        revocation check won’t be performed. However if
        <code>IGN_OCSP_PROXY=true</code> has been supplied it will be
        tried directly. Authentication to the proxy is not supported,
        also no HTTPS or SOCKS proxy.</p>
        <p><code>-6</code> scans only IPv6 addresses of the target.
        Besides the OpenSSL binary supplied IPv6 is known to work with
        vanilla OpenSSL &gt;= 1.1.0 and older versions &gt;=1.0.2 in
        RHEL/CentOS/FC and Gentoo. Scans are somewhat in line with tools
        like curl or wget, i.e. if there’s an IPv6 address of the target
        which can be reached, it just uses them. If you don’t want this
        behavior, you need to supply <code>-4.</code></p>
        <p><code>-4</code> scans only IPv4 addresses of the target, IPv6
        addresses of the target won’t be scanned.</p>
        <p><code>--ssl-native</code> Instead of using a mixture of bash
        sockets and a few openssl s_client connects, testssl.sh uses the
        latter (almost) only. This is faster but provides less accurate
        results, especially for the client simulation and for cipher
        support. For all checks you will see a warning if testssl.sh
        cannot tell if a particular check cannot be performed. For some
        checks however you might end up getting false negatives without
        a warning. Thus it is not recommended to use. It should only be
        used if you prefer speed over accuracy or you know that your
        target has sufficient overlap with the protocols and cipher
        provided by your openssl binary.</p>
        <p><code>--openssl &lt;path_to_openssl&gt;</code> testssl.sh
        tries first very hard to find the binary supplied (where the
        tree of testssl.sh resides, from the directory where testssl.sh
        has been started from, etc.). If all that doesn’t work it falls
        back to openssl supplied from the OS (<code>$PATH</code>). With
        this option you can point testssl.sh to your binary of choice
        and override any internal magic to find the openssl binary.
        (Environment preset via
        <code>OPENSSL=&lt;path_to_openssl&gt;</code>). Depending on your
        test parameters it could be faster to pick the OpenSSL version
        which has a bigger overlap in terms of ciphers protocols with
        the target. Also, when testing a modern server, OpenSSL 3.X is
        faster than older OpenSSL versions, or on MacOS 18, as opposed
        to the provided LibreSSL version.</p>
        <h3 id="tuning-options">TUNING OPTIONS</h3>
        <p><code>--bugs</code> does some workarounds for buggy servers
        like padding for old F5 devices. The option is passed as
        <code>-bug</code> to openssl when needed, see
        <code>s_client(1)</code>, environment preset via
        <code>BUGS="-bugs"</code> (1x dash). For the socket part
        testssl.sh has always workarounds in place to cope with broken
        server implementations.</p>
        <p><code>--assuming-http</code> testssl.sh normally does upfront
        an application protocol detection. In cases where HTTP cannot be
        automatically detected you may want to use this option. It
        enforces testssl.sh not to skip HTTP specific tests (HTTP
        header) and to run a browser based client simulation. Please
        note that sometimes also the severity depends on the application
        protocol, e.g. SHA1 signed certificates, the lack of any SAN
        matches and some vulnerabilities will be punished harder when
        checking a web server as opposed to a mail server.</p>
        <p><code>-n, --nodns &lt;min|none&gt;</code> tells testssl.sh
        which DNS lookups should be performed. <code>min</code> uses
        only forward DNS resolution (A and AAAA record or MX record) and
        skips CAA lookups and PTR records from the IP address back to a
        DNS name. <code>none</code> performs no DNS lookups at all. For
        the latter you either have to supply the IP address as a target,
        to use <code>--ip</code> or have the IP address in
        <code>/etc/hosts</code>. The use of the switch is only useful if
        you either can’t or are not willing to perform DNS lookups. The
        latter can apply e.g. to some pentests. In general this option
        could e.g. help you to avoid timeouts by DNS lookups.
        <code>NODNS</code> is the environment variable for this.
        <code>--nodns=min</code> plus <code>--ip=proxy</code> is useful
        for situations with no local DNS as there’ll be no DNS timeouts
        when trying to resolve CAA, TXT and MX records.</p>
        <p><code>--sneaky</code> For HTTP header checks testssl.sh uses
        normally the server friendly HTTP user agent
        <code>TLS tester from ${URL}</code>. With this option your
        traces are less verbose and a Firefox user agent is being used.
        Be aware that it doesn’t hide your activities. That is just not
        possible (environment preset via <code>SNEAKY=true</code>).</p>
        <p><code>--user-agent &lt;user agent&gt;</code> tells testssl.sh
        to use the supplied HTTP user agent instead of the standard user
        agent <code>TLS tester from ${URL}</code>.</p>
        <p><code>--ids-friendly</code> is a switch which may help to get
        a scan finished which otherwise would be blocked by a server
        side IDS. This switch skips tests for the following
        vulnerabilities: Heartbleed, CCS Injection, Ticketbleed and
        ROBOT. The environment variable OFFENSIVE set to false will
        achieve the same result. Please be advised that as an
        alternative or as a general approach you can try to apply
        evasion techniques by changing the variables USLEEP_SND and / or
        USLEEP_REC and maybe MAX_WAITSOCK.</p>
        <p><code>--phone-out</code> Checking for revoked certificates
        via CRL and OCSP is not done per default. This switch instructs
        testssl.sh to query external – in a sense of the current run –
        URIs. By using this switch you acknowledge that the check might
        have privacy issues, a download of several megabytes (CRL file)
        may happen and there may be network connectivity problems while
        contacting the endpoint which testssl.sh doesn’t handle.
        PHONE_OUT is the environment variable for this which needs to be
        set to true if you want this.</p>
        <p><code>--add-ca &lt;CAfile&gt;</code> enables you to add your
        own CA(s) in PEM format for trust chain checks.
        <code>CAfile</code> can be a directory containing files with a
        .pem extension, a single file or multiple files as a comma
        separated list of root CAs. Internally they will be added during
        runtime to all CA stores. This is (only) useful for internal
        hosts whose certificates are issued by internal CAs.
        Alternatively ADDTL_CA_FILES is the environment variable for
        this.</p>
        <p><code>--rating-only</code> makes testssl.sh do the bare
        minimum to allow rating to succeed. See RATING for more</p>
        <h3 id="single-check-options">SINGLE CHECK OPTIONS</h3>
        <p>Any single check switch supplied as an argument prevents
        testssl.sh from doing a default run. It just takes this and if
        supplied other options and runs them - in the order they would
        also appear in the default run.</p>
        <p><code>-e, --each-cipher</code> checks each of the (currently
        configured) 370 ciphers via openssl + sockets remotely on the
        server and reports back the result in wide mode. If you want to
        display each cipher tested you need to add
        <code>--show-each</code>. Per default it lists the following
        parameters: <code>hexcode</code>,
        <code>OpenSSL cipher suite name</code>,
        <code>key exchange</code>, <code>encryption bits</code>,
        <code>IANA/RFC cipher suite name</code>. Please note the
        <code>--mapping</code> parameter changes what cipher suite names
        you will see here and at which position. Also please note that
        the <strong>bit</strong> length for the encryption is shown and
        not the <strong>security</strong> length, albeit it’ll be sorted
        by the latter. For 3DES due to the Meet-in-the-Middle problem
        the bit size of 168 bits is equivalent to the security size of
        112 bits.</p>
        <p><code>-E, --cipher-per-proto</code> is similar to
        <code>-e, --each-cipher</code>. It checks each of the possible
        ciphers, here: per protocol. If you want to display each cipher
        tested you need to add <code>--show-each</code>. The output is
        sorted by security strength, it lists the encryption bits
        though.</p>
        <p><code>-s, --std, --categories</code> tests certain lists of
        cipher suites / cipher categories by strength.
        (<code>--standard</code> is deprecated.) Those lists are
        (<code>openssl ciphers $LIST</code>, $LIST from below:)</p>
        <ul>
        <li><code>NULL encryption ciphers</code>: ‘NULL:eNULL’</li>
        <li><code>Anonymous NULL ciphers</code>: ‘aNULL:ADH’</li>
        <li><code>Export ciphers</code> (w/o the preceding ones):
        ‘EXPORT:!ADH:!NULL’</li>
        <li><code>LOW</code> (64 Bit + DES ciphers, without EXPORT
        ciphers):
        ‘LOW:DES:RC2:RC4:MD5:!ADH:!EXP:!NULL:!eNULL:!AECDH’</li>
        <li><code>3DES + IDEA ciphers</code>:
        ‘3DES:IDEA:!aNULL:!ADH:!MD5’</li>
        <li><code>Obsoleted CBC ciphers</code>:
        ‘HIGH:MEDIUM:AES:CAMELLIA:ARIA:!IDEA:!CHACHA20:!3DES:!RC2:!RC4:!AESCCM8:!AESCCM:!AESGCM:!ARIAGCM:!aNULL:!MD5’</li>
        <li><code>Strong ciphers with no FS</code> (AEAD):
        ‘AESGCM:CHACHA20:CamelliaGCM:AESCCM:ARIAGCM:!kEECDH:!kEDH:!kDHE:!kDHEPSK:!kECDHEPSK:!aNULL’</li>
        <li><code>Forward Secrecy strong ciphers</code> (AEAD):
        ‘AESGCM:CHACHA20:CamelliaGCM:AESCCM:ARIAGCM:!kPSK:!kRSAPSK:!kRSA:!kDH:!kECDH:!aNULL’</li>
        </ul>
        <p><code>-f, --fs, --nsa, --forward-secrecy</code> Checks robust
        forward secrecy key exchange. “Robust” means that ciphers having
        intrinsic severe weaknesses like Null Authentication or
        Encryption, 3DES and RC4 won’t be considered here. There
        shouldn’t be the wrong impression that a secure key exchange has
        been taking place and everything is fine when in reality the
        encryption sucks. Also this section lists the available
        elliptical curves and Diffie Hellman groups, as well as FFDHE
        groups (TLS 1.2 and TLS 1.3).</p>
        <p><code>-p, --protocols</code> checks every SSL/TLS protocols:
        SSLv2, SSLv3, TLS 1.0 through TLS 1.3. And for HTTP also QUIC
        (HTTP/3), SPDY (NPN) and ALPN (HTTP/2). For TLS 1.3 the final
        version and several drafts (from 18 on) are tested. QUIC needs
        OpenSSL &gt;= 3.2 which can be automatically picked up when in
        <code>/usr/bin/openssl</code> (or when defined environment
        variable OPENSSL2). If a TLS-1.3-only host is encountered and
        the openssl-bad version is used testssl.sh will e.g. for HTTP
        header checks switch to <code>/usr/bin/openssl</code> (or when
        defined via ENV to OPENSSL2). Also this will be tried for the
        QUIC check.</p>
        <p><code>-P, --server-preference, --preference</code> displays
        the servers preferences: cipher order, with used openssl client:
        negotiated protocol and cipher. If there’s a cipher order
        enforced by the server it displays it for each protocol
        (openssl+sockets). If there’s not, it displays instead which
        ciphers from the server were picked with each protocol.</p>
        <p><code>-S, --server_defaults</code> displays information from
        the server hello(s):</p>
        <ul>
        <li>Available TLS extensions,</li>
        <li>TLS ticket + session ID information/capabilities,</li>
        <li>session resumption capabilities,</li>
        <li>TLS 1.3 early data, a.k.a 0-RTT</li>
        <li>Time skew relative to localhost (most server implementations
        return random values).</li>
        <li>Several certificate information
        <ul>
        <li>signature algorithm,</li>
        <li>key size,</li>
        <li>key usage and extended key usage,</li>
        <li>fingerprints and serial</li>
        <li>Common Name (CN), Subject Alternative Name (SAN),
        Issuer,</li>
        <li>Trust via hostname + chain of trust against supplied
        certificates</li>
        <li>EV certificate detection</li>
        <li>experimental “eTLS” detection</li>
        <li>validity: start + end time, how many days to go (warning for
        certificate lifetime &gt;=5 years)</li>
        <li>revocation info (CRL, OCSP, OCSP stapling + must staple).
        When <code>--phone-out</code> supplied it checks against the
        certificate issuer whether the host certificate has been revoked
        (plain OCSP, CRL).</li>
        <li>displaying DNS Certification Authority Authorization
        resource record</li>
        <li>Certificate Transparency info (if provided by server).</li>
        </ul></li>
        </ul>
        <p>For the trust chain check 5 certificate stores are provided.
        If the test against one of the trust stores failed, the one is
        being identified and the reason for the failure is displayed -
        in addition the ones which succeeded are displayed too. You can
        configure your own CA via ADDTL_CA_FILES, see section
        <code>FILES</code> below. If the server provides no matching
        record in Subject Alternative Name (SAN) but in Common Name
        (CN), it will be indicated as this is deprecated. Also for
        multiple server certificates are being checked for as well as
        for the certificate reply to a non-SNI (Server Name Indication)
        client hello to the IP address. Regarding the TLS clock skew: it
        displays the time difference to the client. Only a few TLS
        stacks nowadays still support this and return the local clock
        <code>gmt_unix_time</code>, e.g. IIS, openssl &lt; 1.0.1f. In
        addition to the HTTP date you could e.g. derive that there are
        different hosts where your TLS and your HTTP request ended – if
        the time deltas differ significantly.</p>
        <p><code>-x &lt;pattern&gt;, --single-cipher &lt;pattern&gt;</code>
        tests matched <code>pattern</code> of ciphers against a server.
        Patterns are similar to
        <code>-V pattern , --local pattern</code>, see above about
        matching.</p>
        <p><code>-h, --header, --headers</code> if the service is HTTP
        (either by detection or by enforcing via
        <code>--assume-http</code>. It tests several HTTP headers
        like</p>
        <ul>
        <li>HTTP Strict Transport Security (HSTS)</li>
        <li>HTTP Public Key Pinning (HPKP)</li>
        <li>Server banner</li>
        <li>HTTP date+time</li>
        <li>Server banner like Linux or other Unix vendor headers</li>
        <li>Application banner (PHP, RoR, OWA, SharePoint, Wordpress,
        etc)</li>
        <li>Reverse proxy headers</li>
        <li>Web server modules</li>
        <li>IPv4 address in header</li>
        <li>Cookie (including Secure/HTTPOnly flags)</li>
        <li>Decodes BIG IP F5 non-encrypted cookies</li>
        <li>Security headers (X-Frame-Options, X-XSS-Protection,
        Expect-CT,… , CSP headers). Nonsense is not yet detected
        here.</li>
        </ul>
        <p><code>-c, --client-simulation</code> This simulates a
        handshake with a number of standard clients so that you can
        figure out which client cannot or can connect to your site. For
        the latter case the protocol, cipher and curve is displayed,
        also if there’s Forward Secrecy. testssl.sh uses a handselected
        set of clients which are retrieved by the SSLlabs API. The
        output is aligned in columns when combined with the
        <code>--wide</code> option. If you want the full nine yards of
        clients displayed use the environment variable ALL_CLIENTS.</p>
        <p><code>-g, --grease</code> checks several server
        implementation bugs like tolerance to size limitations and
        GREASE, see RFC 8701. This check doesn’t run per default.</p>
        <h3 id="vulnerabilities">VULNERABILITIES</h3>
        <p><code>-U, --vulnerable, --vulnerabilities</code> Just tests
        all (of the following) vulnerabilities. The environment variable
        <code>VULN_THRESHLD</code> determines after which value a
        separate headline for each vulnerability is being displayed.
        Default is <code>1</code> which means if you check for two
        vulnerabilities, only the general headline for vulnerabilities
        section is displayed – in addition to the vulnerability and the
        result. Otherwise each vulnerability or vulnerability section
        gets its own headline in addition to the output of the name of
        the vulnerability and test result. A vulnerability section is
        comprised of more than one check, e.g. the renegotiation
        vulnerability check has two checks, so has Logjam.</p>
        <p><code>-H, --heartbleed</code> Checks for Heartbleed, a memory
        leakage in openssl. Unless the server side doesn’t support the
        heartbeat extension it is likely that this check runs into a
        timeout. The seconds to wait for a reply can be adjusted with
        <code>HEARTBLEED_MAX_WAITSOCK</code>. 8 is the default.</p>
        <p><code>-I, --ccs, --ccs-injection</code> Checks for CCS
        Injection which is an openssl vulnerability. Sometimes also here
        the check needs to wait for a reply. The predefined timeout of 5
        seconds can be changed with the environment variable
        <code>CCS_MAX_WAITSOCK</code>.</p>
        <p><code>-T, --ticketbleed</code> Checks for Ticketbleed memory
        leakage in BigIP loadbalancers.</p>
        <p><code>--OP, --opossum</code> Checks for HTTP to HTTPS upgrade
        vulnerability named Opossum.</p>
        <p><code>--BB, --robot</code> Checks for vulnerability to ROBOT
        / (<em>Return Of Bleichenbacher’s Oracle Threat</em>)
        attack.</p>
        <p><code>--SI, --starttls-injection</code> Checks for STARTTLS
        injection vulnerabilities (SMTP, IMAP, POP3 only).
        <code>socat</code> and OpenSSL &gt;=1.1.0 is needed.</p>
        <p><code>-R, --renegotiation</code> Tests renegotiation
        vulnerabilities. Currently there’s a check for <em>Secure
        Renegotiation</em> and for <em>Secure Client-Initiated
        Renegotiation</em>. Please be aware that vulnerable servers to
        the latter can likely be DoSed very easily (HTTP). A check for
        <em>Insecure Client-Initiated Renegotiation</em> is not yet
        implemented.</p>
        <p><code>-C, --compression, --crime</code> Checks for CRIME
        (<em>Compression Ratio Info-leak Made Easy</em>) vulnerability
        in TLS. CRIME in SPDY is not yet being checked for.</p>
        <p><code>-B, --breach</code> Checks for BREACH (<em>Browser
        Reconnaissance and Exfiltration via Adaptive Compression of
        Hypertext</em>) vulnerability. As for this vulnerability HTTP
        level compression is a prerequisite it’ll be not tested if HTTP
        cannot be detected or the detection is not enforced via
        <code>--assume-http</code>. Please note that only the URL
        supplied (normally “/” ) is being tested.</p>
        <p><code>-O, --poodle</code> Tests for SSL POODLE (<em>Padding
        Oracle On Downgraded Legacy Encryption</em>) vulnerability. It
        basically checks for the existence of CBC ciphers in SSLv3.</p>
        <p><code>-Z, --tls-fallback</code> Checks TLS_FALLBACK_SCSV
        mitigation. TLS_FALLBACK_SCSV is basically a ciphersuite
        appended to the Client Hello trying to prevent protocol
        downgrade attacks by a Man in the Middle.</p>
        <p><code>-W, --sweet32</code> Checks for vulnerability to
        SWEET32 by testing 64 bit block ciphers (3DES, RC2 and
        IDEA).</p>
        <p><code>-F, --freak</code> Checks for FREAK vulnerability
        (<em>Factoring RSA Export Keys</em>) by testing for EXPORT RSA
        ciphers</p>
        <p><code>-D, --drown</code> Checks for DROWN vulnerability
        (<em>Decrypting RSA with Obsolete and Weakened eNcryption</em>)
        by checking whether the SSL 2 protocol is available at the
        target. Please note that if you use the same RSA certificate
        elsewhere you might be vulnerable too. testssl.sh doesn’t check
        for this but provides a helpful link @ censys.io which provides
        this service.</p>
        <p><code>-J, --logjam</code> Checks for LOGJAM vulnerability by
        checking for DH EXPORT ciphers. It also checks for “common
        primes” which are preconfigured DH keys. DH keys =&lt; 1024 Bit
        will be penalized. Also FFDHE groups (TLS 1.2) will be displayed
        here.</p>
        <p><code>-A, --beast</code> Checks BEAST vulnerabilities in SSL
        3 and TLS 1.0 by testing the usage of CBC ciphers.</p>
        <p><code>-L, --lucky13</code> Checks for LUCKY13 vulnerability.
        It checks for the presence of CBC ciphers in TLS versions 1.0 -
        1.2.</p>
        <p><code>-WS, --winshock</code> Checks for Winshock
        vulnerability. It tests for the absence of a lot of ciphers,
        some TLS extensions and ec curves which were introduced later in
        Windows. In the end the server banner is being looked at.</p>
        <p><code>--rc4, --appelbaum</code> Checks which RC4 stream
        ciphers are being offered.</p>
        <h3 id="output-options">OUTPUT OPTIONS</h3>
        <p><code>-q, --quiet</code> Normally testssl.sh displays a
        banner on stdout with several version information, usage rights
        and a warning. This option suppresses it. Please note that by
        choosing this option you acknowledge usage terms and the warning
        normally appearing in the banner.</p>
        <p><code>--wide</code> Except the “each cipher output” all tests
        displays the single cipher name (scheme see below). This option
        enables testssl.sh to display also for the following sections
        the same output as for testing each ciphers: BEAST, FS, RC4. The
        client simulation has also a wide mode. The difference here is
        restricted to a column aligned output and a proper headline. The
        environment variable <code>WIDE</code> can be used instead.</p>
        <p><code>--mapping &lt;openssl|iana|no-openssl|no-iana&gt;</code></p>
        <ul>
        <li><code>openssl</code>: use the OpenSSL cipher suite name as
        the primary name cipher suite name form (default),</li>
        <li><code>iana</code>: use the IANA cipher suite name as the
        primary name cipher suite name form.</li>
        <li><code>no-openssl</code>: don’t display the OpenSSL cipher
        suite name, display IANA names only.</li>
        <li><code>no-iana</code>: don’t display the IANA cipher suite
        name, display OpenSSL names only.</li>
        </ul>
        <p>Please note that in testssl.sh 3.0 you can still use
        <code>rfc</code> instead of <code>iana</code> and
        <code>no-rfc</code> instead of <code>no-iana</code> but it’ll
        disappear after 3.0.</p>
        <p><code>--show-each</code> This is an option for all wide modes
        only: it displays all ciphers tested – not only succeeded ones.
        <code>SHOW_EACH_C</code> is your friend if you prefer to set
        this via the shell environment.</p>
        <p><code>--color &lt;0|1|2|3&gt;</code> determines the use of
        colors on the screen and in the log file: <code>2</code> is the
        default and makes use of ANSI and termcap escape codes on your
        terminal. <code>1</code> just uses non-colored mark-up like
        bold, italics, underline, reverse. <code>0</code> means no
        mark-up at all = no escape codes. This is also what you want
        when you want a log file without any escape codes.
        <code>3</code> will color ciphers and EC according to an
        internal (not yet perfect) rating. Setting the environment
        variable <code>COLOR</code> to the value achieves the same
        result. Please not that OpenBSD and early FreeBSD do not support
        italics.</p>
        <p><code>--colorblind</code> Swaps green and blue colors in the
        output, so that this percentage of folks (up to 8% of males, see
        https://en.wikipedia.org/wiki/Color_blindness) can distinguish
        those findings better. <code>COLORBLIND</code> is the according
        variable if you want to set this in the environment.</p>
        <p><code>--debug &lt;0-6&gt;</code> This gives you additional
        output on the screen (2-6), only useful for debugging.
        <code>DEBUG</code> is the according environment variable which
        you can use. There are six levels (0 is the default, thus it has
        no effect):</p>
        <ol type="1">
        <li>screen output normal but leaves useful debug output in
        <strong>/tmp/testssl.XXXXXX/</strong> . The info about the exact
        directory is included in the screen output in the end of the
        run.</li>
        <li>lists more what’s going on, status (high level) and
        connection errors, a few general debug output</li>
        <li>even slightly more info: hexdumps + other info</li>
        <li>display bytes sent via sockets</li>
        <li>display bytes received via sockets</li>
        <li>whole 9 yards</li>
        </ol>
        <p><code>--disable-rating</code> disables rating. Rating
        automatically gets disabled, to not give a wrong or misleading
        grade, when not all required functions are executed (e.g when
        checking for a single vulnerabilities).</p>
        <h3 id="file-output-options">FILE OUTPUT OPTIONS</h3>
        <p><code>--log, --logging</code> Logs stdout also to
        <code>${NODE}-p${port}${YYYYMMDD-HHMM}.log</code> in current
        working directory of the shell. Depending on the color output
        option (see above) the output file will contain color and other
        markup escape codes, unless you specify <code>--color 0</code>
        too. <code>cat</code> and – if properly configured
        <code>less</code> – will show the output properly formatted on
        your terminal. The output shows a banner with the almost the
        same information as on the screen. In addition it shows the
        command line of the testssl.sh instance. Please note that the
        resulting log file is formatted according to the width of your
        screen while running testssl.sh. You can override the width with
        the environment variable TERM_WIDTH.</p>
        <p><code>--logfile &lt;logfile&gt;</code> or
        <code>-oL &lt;logfile&gt;</code> Instead of the previous option
        you may want to use this one if you want to log into a directory
        or if you rather want to specify the log file name yourself. If
        <code>logfile</code> is a directory the output will put into
        <code>logfile/${NODE}-p${port}${YYYYMMDD-HHMM}.log</code>. If
        <code>logfile</code> is a file it will use that file name, an
        absolute path is also permitted here. LOGFILE is the variable
        you need to set if you prefer to work environment variables
        instead. Please note that the resulting log file is formatted
        according to the width of your screen while running testssl.sh.
        You can override the width with the environment variable
        TERM_WIDTH.</p>
        <p><code>--json</code> Logs additionally to JSON file
        <code>${NODE}-p${port}${YYYYMMDD-HHMM}.json</code> in the
        current working directory of the shell. The resulting JSON file
        is opposed to <code>--json-pretty</code> flat – which means each
        section is self contained and has an identifier for each single
        check, the hostname/IP address, the port, severity and the
        finding. For vulnerabilities it may contain a CVE and CWE entry
        too. The output doesn’t contain a banner or a footer.</p>
        <p><code>--jsonfile &lt;jsonfile&gt;</code> or
        <code>-oj &lt;jsonfile&gt;</code> Instead of the previous option
        you may want to use this one if you want to log the JSON out put
        into a directory or if you rather want to specify the log file
        name yourself. If <code>jsonfile</code> is a directory the
        output will put into
        <code>logfile/${NODE}-p${port}${YYYYMMDD-HHMM}.json</code>. If
        <code>jsonfile</code> is a file it will use that file name, an
        absolute path is also permitted here.</p>
        <p><code>--json-pretty</code> Logs additionally to JSON file
        <code>${NODE}-p${port}${YYYYMMDD-HHMM}.json</code> in the
        current working directory of the shell. The resulting JSON file
        is opposed to <code>--json</code> non-flat – which means it is
        structured. The structure contains a header similar to the
        banner on the screen, including the command line, scan host,
        openssl binary used, testssl version and epoch of the start
        time. Then for every test section of testssl.sh it contains a
        separate JSON object/section. Each finding has a key/value pair
        identifier with the identifier for each single check, the
        severity and the finding. For vulnerabilities it may contain a
        CVE and CWE entry too. The footer lists the scan time in
        seconds.</p>
        <p><code>--jsonfile-pretty &lt;jsonfile&gt;</code> or
        <code>-oJ &lt;jsonfile&gt;</code> Similar to the aforementioned
        <code>--jsonfile</code> or <code>--logfile</code> it logs the
        output in pretty JSON format (see <code>--json-pretty</code>)
        into a file or a directory. For further explanation see
        <code>--jsonfile</code> or <code>--logfile</code>.</p>
        <p><code>--csv</code> Logs additionally to a CSV file
        <code>${NODE}-p${port}${YYYYMMDD-HHMM}.csv</code> in the current
        working directory of the shell. The output contains a header
        with the keys, the values are the same as in the flat JSON
        format (identifier for each single check, the hostname/IP
        address, the port, severity, the finding and for vulnerabilities
        a CVE and CWE number).</p>
        <p><code>--csvfile &lt;csvfile&gt;</code> or
        <code>-oC &lt;csvfile&gt;</code> Similar to the aforementioned
        <code>--jsonfile</code> or <code>--logfile</code> it logs the
        output in CSV format (see <code>--cvs</code>) additionally into
        a file or a directory. For further explanation see
        <code>--jsonfile</code> or <code>--logfile</code>.</p>
        <p><code>--html</code> Logs additionally to an HTML file
        <code>${NODE}-p${port}${YYYYMMDD-HHMM}.html</code> in the
        current working directory of the shell. It contains a 1:1 output
        of the console. In former versions there was a non-native option
        to use “aha” (Ansi HTML Adapter: github.com/theZiz/aha) like
        <code>testssl.sh [options] &lt;URI&gt; | aha &gt;output.html</code>.
        This is not necessary anymore.</p>
        <p><code>--htmlfile &lt;htmlfile&gt;</code> or
        <code>-oH &lt;htmlfile&gt;</code> Similar to the aforementioned
        <code>--jsonfile</code> or <code>--logfile</code> it logs the
        output in HTML format (see <code>--html</code>) additionally
        into a file or a directory. For further explanation see
        <code>--jsonfile</code> or <code>--logfile</code>.</p>
        <p><code>-oA &lt;filename&gt;</code> /
        <code>--outFile &lt;filename&gt;</code> Similar to nmap it does
        a file output to all available file formats: LOG, JSON pretty,
        CSV, HTML. If the filename supplied is equal <code>auto</code>
        the filename is automatically generated using ‘<span
        class="math inline"><em>N</em><em>O</em><em>D</em><em>E</em> − <em>p</em></span>{port}<span
        class="math inline"><em>Y</em><em>Y</em><em>Y</em><em>Y</em><em>M</em><em>M</em><em>D</em><em>D</em> − <em>H</em><em>H</em><em>M</em><em>M</em>.</span>{EXT}’
        with the according extension. If a directory is provided all
        output files will put into
        <code>&lt;filename&gt;/${NODE}-p${port}${YYYYMMDD-HHMM}.{log,json,csv,html}</code>.</p>
        <p><code>-oa &lt;filename&gt;</code> /
        <code>--outfile &lt;filename&gt;</code> Does the same as the
        previous option but uses flat JSON instead.</p>
        <p><code>--hints</code> This option is not in use yet. This
        option is meant to give hints how to fix a finding or at least a
        help to improve something. GIVE_HINTS is the environment
        variable for this.</p>
        <p><code>--severity &lt;severity&gt;</code> For CSV and both
        JSON outputs this will only add findings to the output file if a
        severity is equal or higher than the <code>severity</code> value
        specified. Allowed are
        <code>&lt;LOW|MEDIUM|HIGH|CRITICAL&gt;</code>. WARN is another
        level which translates to a client-side scanning error or
        problem. Thus you will always see them in a file if they
        occur.</p>
        <p><code>--append</code> Normally, if an output file already
        exists and it has a file size greater zero, testssl.sh will
        prompt you to manually remove the file and exit with an error.
        <code>--append</code> however will append to this file, without
        a header. The environment variable APPEND does the same. Be
        careful using this switch/variable. A complementary option which
        overwrites an existing file doesn’t exist per design.</p>
        <p><code>--overwrite</code> Normally, if an output file already
        exists and it has a file size greater zero, testssl.sh will not
        allow you to overwrite this file. This option will do that
        <strong>without any warning</strong>. The environment variable
        OVERWRITE does the same. Be careful, you have been warned!</p>
        <p><code>--outprefix &lt;fname_prefix&gt;</code> Prepend output
        filename prefix <fname_prefix> before <code>${NODE}-</code>. You
        can use as well the environment variable FNAME_PREFIX. Using
        this any output files will be named
        <code>&lt;fname_prefix&gt;-${NODE}-p${port}${YYYYMMDD-HHMM}.&lt;format&gt;</code>
        when no file name of the respective output option was specified.
        If you do not like the separator ‘-’ you can as well supply a
        <code>&lt;fname_prefix&gt;</code> ending in ‘.’, ’_’ or ‘,’. In
        this case or if you already supplied ‘-’ no additional ‘-’ will
        be appended to <code>&lt;fname_prefix&gt;</code>.</p>
        <p>A few file output options can also be preset via environment
        variables.</p>
        <h3 id="color-ratings">COLOR RATINGS</h3>
        <p>Testssl.sh makes use of (the eight) standard terminal colors.
        The color scheme is as follows:</p>
        <ul>
        <li>light red: a critical finding</li>
        <li>red: a high finding</li>
        <li>brown: a medium finding</li>
        <li>yellow: a low finding</li>
        <li>green (blue if COLORBLIND is set): something which is either
        in general a good thing or a negative result of a check which
        otherwise results in a high finding</li>
        <li>light green (light blue if COLORBLIND is set) : something
        which is either in general a very good thing or a negative
        result of a check which otherwise results in a critical
        finding</li>
        <li>no color at places where also a finding can be expected: a
        finding on an info level</li>
        <li>cyan: currently only used for <code>--show-each</code> or an
        additional hint</li>
        <li>magenta: signals a warning condition, e.g. either a local
        lack of capabilities on the client side or another problem</li>
        <li>light magenta: a fatal error which either requires strict
        consent from the user to continue or a condition which leaves no
        other choice for testssl.sh to quit</li>
        </ul>
        <p>What is labeled as “light” above appears as such on the
        screen but is technically speaking “bold”. Besides
        <code>--color=3</code> will color ciphers according to an
        internal and rough rating.</p>
        <p>Markup (without any color) is used in the following
        manner:</p>
        <ul>
        <li>bold: for the name of the test</li>
        <li>underline + bold: for the headline of each test section</li>
        <li>underline: for a sub-headline</li>
        <li>italics: for strings just reflecting a value read from the
        server</li>
        </ul>
        <h3 id="tuning-via-env-variables-and-more-options">TUNING via
        ENV variables and more options</h3>
        <p>Except the environment variables mentioned above which can
        replace command line options here a some which cannot be set
        otherwise. Variables used for tuning are preset with reasonable
        values. <em>There should be no reason to change them</em> unless
        you use testssl.sh under special conditions.</p>
        <ul>
        <li>TERM_WIDTH is a variable which overrides the auto-determined
        terminal width size. Setting this variable normally only makes
        sense if you log the output to a file using the
        <code>--log</code>, <code>--logfile</code> or <code>-oL</code>
        option.</li>
        <li>DEBUG_ALLINONE / SETX: when setting one of those to true
        testssl.sh falls back to the standard bash behavior,
        i.e. calling <code>bash -x testssl.sh</code> it displays the
        bash debugging output not in an external file
        <code>/tmp/testssl-&lt;XX&gt;.log</code></li>
        <li>DEBUGTIME: Profiling option. When using bash’s debug mode
        and when this is set to true, it generates a separate text file
        with epoch times in <code>/tmp/testssl-&lt;XX&gt;.time</code>.
        They need to be concatenated by
        <code>paste /tmp/testssl-&lt;XX&gt;.{time,log}</code>
        &lt;!—</li>
        <li>FAST_SOCKET</li>
        <li>SHOW_SIGALGO</li>
        <li>FAST –&gt;</li>
        <li>EXPERIMENTAL=true is an option which is sometimes used in
        the development process to make testing easier. In released
        versions this has no effect.</li>
        <li>ALL_CLIENTS=true runs a client simulation with <em>all</em>
        (currently 126) clients when testing HTTP.</li>
        <li>UNBRACKTD_IPV6: needs to be set to true for some old
        versions of OpenSSL (like from Gentoo) which don’t support
        [bracketed] IPv6 addresses</li>
        <li>NO_ENGINE: if you have problems with garbled output
        containing the word ‘engine’ you might want to set this to true.
        It forces testssl.sh not try to configure openssl’s engine or a
        non existing one from libressl</li>
        <li>HEADER_MAXSLEEP: To wait how long before killing the process
        to retrieve a service banner / HTTP header</li>
        <li>MAX_WAITSOCK: It instructs testssl.sh to wait until the
        specified time before declaring a socket connection dead. Don’t
        change this unless you’re absolutely sure what you’re doing.
        Value is in seconds.</li>
        <li>CCS_MAX_WAITSOCK Is the similar to above but applies only to
        the CCS handshakes, for both of the two the two CCS payload.
        Don’t change this unless you’re absolutely sure what you’re
        doing. Value is in seconds.</li>
        <li>HEARTBLEED_MAX_WAITSOCK Is the similar to MAX_WAITSOCK but
        applies only to the ServerHello after sending the Heartbleed
        payload. Don’t change this unless you’re absolutely sure what
        you’re doing. Value is in seconds.</li>
        <li>MEASURE_TIME_FILE For seldom cases when you don’t want the
        scan time to be included in the output you can set this to
        false.</li>
        <li>STARTTLS_SLEEP is per default set to 10 (seconds). That’s
        the value testssl.sh waits for a string in the STARTTLS
        handshake before giving up.</li>
        <li>MAX_PARALLEL is the maximum number of tests to run in
        parallel in parallel mass testing mode. The default value of 20
        may be made larger on systems with faster processors.</li>
        <li>MAX_WAIT_TEST is the maximum time (in seconds) to wait for a
        single test in parallel mass testing mode to complete. The
        default is 1200. &lt;!—</li>
        <li>USLEEP_SND</li>
        <li>USLEEP_REC –&gt;</li>
        <li>HSTS_MIN is preset to 179 (days). If you want warnings
        sooner or later for HTTP Strict Transport Security you can
        change this.</li>
        <li>HPKP_MIN is preset to 30 (days). If you want warnings sooner
        or later for HTTP Public Key Pinning you can change this</li>
        <li>DAYS2WARN1 is the first threshold when you’ll be warning of
        a certificate expiration of a host, preset to 60 (days). For
        Let’s Encrypt this value will be divided internally by 2.</li>
        <li>DAYS2WARN2 is the second threshold when you’ll be warning of
        a certificate expiration of a host, preset to 30 (days). For
        Let’s Encrypt this value will be divided internally by 2.</li>
        <li>TESTSSL_INSTALL_DIR is the derived installation directory of
        testssl.sh. Relatively to that the <code>bin</code> and
        mandatory <code>etc</code> directory will be looked for.</li>
        <li>CA_BUNDLES_PATH: If you have an own set of CA bundles or you
        want to point testssl.sh to a specific location of a CA bundle,
        you can use this variable to set the directory which testssl.sh
        will use. Please note that it overrides completely the builtin
        path of testssl.sh which means that you will only test against
        the bundles you point to. Also you might want to use
        <code>~/utils/create_ca_hashes.sh</code> to create the hashes
        for HPKP.</li>
        <li>MAX_SOCKET_FAIL: A number which tells testssl.sh how often a
        TCP socket connection may fail before the program gives up and
        terminates. The default is 2. You can increase it to a higher
        value if you frequently see a message like <em>Fatal error:
        repeated openssl s_client connect problem, doesn’t make sense to
        continue</em>.</li>
        <li>MAX_OSSL_FAIL: A number which tells testssl.sh how often an
        OpenSSL s_client connect may fail before the program gives up
        and terminates. The default is 2. You can increase it to a
        higher value if you frequently see a message like <em>Fatal
        error: repeated TCP connect problems, giving up</em>.</li>
        <li>MAX_HEADER_FAIL: A number which tells testssl.sh how often a
        HTTP GET request over OpenSSL may return an empty file before
        the program gives up and terminates. The default is 3. Also here
        you can increase the threshold when you spot messages like
        <em>Fatal error: repeated HTTP header connect problems, doesn’t
        make sense to continue</em>.</li>
        <li>OPENSSL2 can be used to supply an alternative openssl
        version. This only makes sense if you want to amend the supplied
        version in <code>bin/</code> which lacks TLS 1.3 support with a
        version which doesn not and is not in
        <code>/usr/bin/openssl</code>.</li>
        <li>OSSL_SHORTCUT should be set to false when you run
        interactively and don’t want to switch automatically to
        <code>/usr/bin/openssl</code> (<code>OPENSSL2</code>) if you
        encounter a TLS 1.3-only host.</li>
        </ul>
        <h3 id="rating">RATING</h3>
        <p>This program has a near-complete implementation of SSL Labs’s
        ‘<a
        href="https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide">SSL
        Server Rating Guide</a>’.</p>
        <p>This is <em>not</em> a 100% reimplementation of the <a
        href="https://www.ssllabs.com/ssltest/analyze.html">SSL Lab’s
        SSL Server Test</a>, but an implementation of the above rating
        specification, slight discrepancies may occur. Please note that
        for now we stick to the SSL Labs rating as good as possible. We
        are not responsible for their rating. Before filing issues
        please inspect their Rating Guide.</p>
        <p>Disclaimer: Having a good grade is <strong>NOT</strong>
        necessarily equal to having good security! Don’t start a
        competition for the best grade, at least not without monitoring
        the client handshakes and not without adding a portion of good
        sense to it. Please note STARTTLS always results in a grade cap
        to T. Anything else would lead to a false sense of security. Use
        TLS, see also RFC 8314. The security of STARTTLS is always
        client determined, i.e. checking the certificate which for SMTP
        port 25 is often enough not the case. Also with DANE or MTA-STS
        no one can test on the server side whether a client makes use if
        it.</p>
        <p>As of writing, these checks are missing:</p>
        <ul>
        <li>GOLDENDOODLE - should be graded <strong>F</strong> if
        vulnerable</li>
        <li>Insecure renegotiation - should be graded <strong>F</strong>
        if vulnerable</li>
        <li>Padding oracle in AES-NI CBC MAC check (CVE-2016-2107) -
        should be graded <strong>F</strong> if vulnerable</li>
        <li>Sleeping POODLE - should be graded <strong>F</strong> if
        vulnerable</li>
        <li>Zero Length Padding Oracle (CVE-2019-1559) - should be
        graded <strong>F</strong> if vulnerable</li>
        <li>Zombie POODLE - should be graded <strong>F</strong> if
        vulnerable</li>
        <li>All remaining old Symantec PKI certificates are distrusted -
        should be graded <strong>T</strong></li>
        <li>Symantec certificates issued before June 2016 are distrusted
        - should be graded <strong>T</strong></li>
        <li>Anonymous key exchange - should give <strong>0</strong>
        points in <code>set_key_str_score()</code></li>
        <li>Exportable key exchange - should give <strong>40</strong>
        points in <code>set_key_str_score()</code></li>
        <li>Weak key (Debian OpenSSL Flaw) - should give
        <strong>0</strong> points in
        <code>set_key_str_score()</code></li>
        </ul>
        <h4 id="implementing-new-grades-caps-or--warnings">Implementing
        new grades caps or -warnings</h4>
        <p>To implement a new grading cap, simply call the
        <code>set_grade_cap()</code> function, with the grade and a
        reason:</p>
        <div class="sourceCode" id="cb2"><pre
        class="sourceCode bash"><code class="sourceCode bash"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="ex">set_grade_cap</span> <span class="st">&quot;D&quot;</span> <span class="st">&quot;Vulnerable to documentation&quot;</span></span></code></pre></div>
        <p>To implement a new grade warning, simply call the
        <code>set_grade_warning()</code> function, with a message:</p>
        <div class="sourceCode" id="cb3"><pre
        class="sourceCode bash"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="ex">set_grade_warning</span> <span class="st">&quot;Documentation is always right&quot;</span></span></code></pre></div>
        <h4
        id="implementing-a-new-check-which-contains-grade-caps">Implementing
        a new check which contains grade caps</h4>
        <p>When implementing a new check (be it vulnerability or not)
        that sets grade caps, the <code>set_rating_state()</code> has to
        be updated (i.e. the <code>$do_mycheck</code> variable-name has
        to be added to the loop, and <code>$nr_enabled</code>
        if-statement has to be incremented), and the
        <code>--rating-only</code> switch statement needs to have
        <code>$do_mycheck=true</code> added</p>
        <p>The <code>set_rating_state()</code> automatically disables
        rating, if all the required checks are <em>not</em> enabled.
        This is to prevent giving out a misleading or wrong grade.</p>
        <h4 id="implementing-a-new-revision">Implementing a new
        revision</h4>
        <p>When a new revision of the rating specification comes around,
        the following has to be done:</p>
        <ul>
        <li>New grade caps has to be either:
        <ol type="1">
        <li>Added to the script wherever relevant, or</li>
        <li>Added to the above list of missing checks (if above is not
        possible)</li>
        </ol></li>
        <li>New grade warnings has to be added wherever relevant</li>
        <li>The revision output in <code>run_rating()</code> function
        has to updated</li>
        </ul>
        <h2 id="examples">EXAMPLES</h2>
        <pre><code>  testssl.sh testssl.sh</code></pre>
        <p>does a default run on https://testssl.sh (protocols, standard
        cipher lists, server’s cipher preferences, forward secrecy,
        server defaults, vulnerabilities, client simulation, and
        rating.</p>
        <pre><code>  testssl.sh testssl.net:443</code></pre>
        <p>does the same default run as above with the subtle difference
        that testssl.net has two IPv4 addresses. Both are tested.</p>
        <pre><code>  testssl.sh --ip=one --wide https://testssl.net:443</code></pre>
        <p>does the same checks as above, with the difference that one
        IP address is being picked randomly. Displayed is everything
        where possible in wide format.</p>
        <pre><code>  testssl.sh -6 https://testssl.net</code></pre>
        <p>As opposed to the first example it also tests the IPv6 part –
        supposed you have an IPv6 network and your openssl supports IPv6
        (see above).</p>
        <pre><code>  testssl.sh -t smtp smtp.gmail.com:25</code></pre>
        <p>Checks are done via a STARTTLS handshake on the plain text
        port 25. It checks every IP on smtp.gmail.com.</p>
        <pre><code>    testssl.sh --starttls=imap imap.gmx.net:143</code></pre>
        <p>does the same on the plain text IMAP port.</p>
        <p>Please note that for plain TLS-encrypted ports you must not
        specify the protocol option when no STARTTLS handshake is
        offered: <code>testssl.sh smtp.gmail.com:465</code> just checks
        the encryption on the SMTPS port,
        <code>testssl.sh imap.gmx.net:993</code> on the IMAPS port. Also
        MongoDB which provides TLS support without STARTTLS can be
        tested directly.</p>
        <h2 id="rfcs-and-other-standards">RFCs and other standards</h2>
        <ul>
        <li>RFC 2246: The TLS Protocol Version 1.0</li>
        <li>RFC 2595: Using TLS with IMAP, POP3 and ACAP</li>
        <li>RFC 2817: Upgrading to TLS Within HTTP/1.1</li>
        <li>RFC 2818: HTTP Over TLS</li>
        <li>RFC 2830: Lightweight Directory Access Protocol (v3):
        Extension for Transport Layer Security</li>
        <li>RFC 3207: SMTP Service Extension for Secure SMTP over
        Transport Layer Security</li>
        <li>RFC 3501: INTERNET MESSAGE ACCESS PROTOCOL - VERSION
        4rev1</li>
        <li>RFC 4346: The Transport Layer Security (TLS) Protocol
        Version 1.1</li>
        <li>RFC 4366: Transport Layer Security (TLS) Extensions</li>
        <li>RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites
        for Transport Layer Security (TLS)</li>
        <li>RFC 5077: Transport Layer Security (TLS) Session
        Resumption</li>
        <li>RFC 5246: The Transport Layer Security (TLS) Protocol
        Version 1.2</li>
        <li>RFC 5280: Internet X.509 Public Key Infrastructure
        Certificate and Certificate Revocation List (CRL) Profile</li>
        <li>RFC 5321: Simple Mail Transfer Protocol</li>
        <li>RFC 5746: Transport Layer Security (TLS) Renegotiation
        Indication Extension</li>
        <li>RFC 5804: A Protocol for Remotely Managing Sieve
        Scripts</li>
        <li>RFC 6066: Transport Layer Security (TLS) Extensions:
        Extension Definitions</li>
        <li>RFC 6101: The Secure Sockets Layer (SSL) Protocol Version
        3.0</li>
        <li>RFC 6120: Extensible Messaging and Presence Protocol (XMPP):
        Core</li>
        <li>RFC 6125: Domain-Based Application Service Identity
        [..]</li>
        <li>RFC 6797: HTTP Strict Transport Security (HSTS)</li>
        <li>RFC 6961: The Transport Layer Security (TLS) Multiple
        Certificate Status Request Extension</li>
        <li>RFC 7469: Public Key Pinning Extension for HTTP (HPKP)</li>
        <li>RFC 7507: TLS Fallback Signaling Cipher Suite Value (SCSV)
        for Preventing Protocol Downgrade Attacks</li>
        <li>RFC 7627: Transport Layer Security (TLS) Session Hash and
        Extended Master Secret Extension</li>
        <li>RFC 7633: X.509v3 Transport Layer Security (TLS) Feature
        Extension</li>
        <li>RFC 7465: Prohibiting RC4 Cipher Suites</li>
        <li>RFC 7685: A Transport Layer Security (TLS) ClientHello
        Padding Extension</li>
        <li>RFC 7905: ChaCha20-Poly1305 Cipher Suites for Transport
        Layer Security (TLS)</li>
        <li>RFC 7919: Negotiated Finite Field Diffie-Hellman Ephemeral
        Parameters for Transport Layer Security</li>
        <li>RFC 8143: Using Transport Layer Security (TLS) with Network
        News Transfer Protocol (NNTP)</li>
        <li>RFC 8446: The Transport Layer Security (TLS) Protocol
        Version 1.3</li>
        <li>RFC 8470: Using Early Data in HTTP</li>
        <li>RFC 8701: Applying Generate Random Extensions And Sustain
        Extensibility (GREASE) to TLS Extensibility</li>
        <li>RFC 9000: QUIC: A UDP-Based Multiplexed and Secure
        Transport</li>
        <li>W3C CSP: Content Security Policy Level 1-3</li>
        <li>TLSWG Draft: The Transport Layer Security (TLS) Protocol
        Version 1.3</li>
        <li>FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism
        Standard</li>
        </ul>
        <p><a
        href="ihttps://www.rfc-editor.org/search/rfc_search_detail.php?title=TLS&amp;page=All">More
        RFCs</a> might be applicable.</p>
        <h2 id="exit-status">EXIT STATUS</h2>
        <ul>
        <li>0 testssl.sh finished successfully without errors and
        without ambiguous results</li>
        <li>1 testssl.sh has encountered exactly one ambiguous situation
        or an error during run</li>
        <li>1+n same as previous. The errors or ambiguous results are
        added, also per IP.</li>
        <li>50-200 reserved for returning a vulnerability scoring for
        system monitoring or a CI tools</li>
        <li>242 (ERR_CHILD) Child received a signal from master</li>
        <li>244 (ERR_RESOURCE) Resources testssl.sh needs couldn’t be
        read</li>
        <li>245 (ERR_CLUELESS) Weird state, either though user options
        or testssl.sh</li>
        <li>246 (ERR_CONNECT) Connectivity problem</li>
        <li>247 (ERR_DNSLOOKUP) Problem with resolving IP addresses or
        names</li>
        <li>248 (ERR_OTHERCLIENT) Other client problem</li>
        <li>249 (ERR_DNSBIN) Problem with DNS lookup binaries</li>
        <li>250 (ERR_OSSLBIN) Problem with OpenSSL binary</li>
        <li>251 (ERR_NOSUPPORT) Feature requested is not supported</li>
        <li>252 (ERR_FNAMEPARSE) Input file couldn’t be parsed</li>
        <li>253 (ERR_FCREATE) Output file couldn’t be created</li>
        <li>254 (ERR_CMDLINE) Cmd line couldn’t be parsed</li>
        <li>255 (ERR_BASH) Bash version incorrect</li>
        </ul>
        <h2 id="files">FILES</h2>
        <p><strong>etc/*pem</strong> are the certificate stores from
        Apple, Linux, Mozilla Firefox, Windows and Java.</p>
        <p><strong>etc/client-simulation.txt</strong> contains client
        simulation data.</p>
        <p><strong>etc/cipher-mapping.txt</strong> provides a mandatory
        file with mapping from OpenSSL cipher suites names to the ones
        from IANA / used in the RFCs.</p>
        <p><strong>etc/tls_data.txt</strong> provides a mandatory file
        for ciphers (bash sockets) and key material.</p>
        <h2 id="authors">AUTHORS</h2>
        <p>Developed by Dirk Wetter, David Cooper and many others, see
        CREDITS.md .</p>
        <h2 id="copyright">COPYRIGHT</h2>
        <p>Copyright © 2012 Dirk Wetter. License GPLv2: Free Software
        Foundation, Inc. This is free software: you are free to change
        and redistribute it under the terms of the license, see
        LICENSE.</p>
        <p>Attribution is important for the future of this project -
        also in the internet. Thus if you’re offering a scanner based on
        testssl.sh as a public and/or paid service in the internet you
        are strongly encouraged to mention to your audience that you’re
        using this program and where to get this program from. That
        helps us to get bugfixes, other feedback and more
        contributions.</p>
        <p>Usage WITHOUT ANY WARRANTY. USE at your OWN RISK!</p>
        <h2 id="limitation">LIMITATION</h2>
        <p>All native Windows platforms emulating Linux are known to be
        slow.</p>
        <h2 id="bugs">BUGS</h2>
        <p>Probably. Current known ones and interface for filing new
        ones: https://testssl.sh/bugs/ .</p>
        <h2 id="see-also">SEE ALSO</h2>
        <p><code>ciphers</code>(1), <code>openssl</code>(1),
        <code>s_client</code>(1), <code>x509</code>(1),
        <code>verify</code>(1), <code>ocsp</code>(1),
        <code>crl</code>(1), <code>bash</code>(1) and the websites
        https://testssl.sh/ and https://github.com/testssl/testssl.sh/
        .</p>
    </body>
</html>
